Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename QUIT_GAP, FORCE_QUIT_GAP and GAP_EXIT_CODE to QuitGap, ForceQuitGap and GapExitCode (the old names remain available as synonyms) #3862

Merged
merged 2 commits into from
May 28, 2020

Conversation

ChrisJefferson
Copy link
Contributor

A usual gap rule is CamelCase functions are for users, and ALL_CAPS are internal.

I think enough people are now using QUIT_GAP, FORCE_QUIT_GAP and GAP_EXIT_CODE that they should be moved to CamelCase (obviously leaving the old ALL_CAPS versions as obsolete).

@ChrisJefferson
Copy link
Contributor Author

We could decide that QUIT_GAP -> QuitGap is OK, but leave FORCE_QUIT_GAP as all caps, as that function is "less user safe"...

@ChrisJefferson ChrisJefferson added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Jan 20, 2020
@coveralls
Copy link

coveralls commented Jan 20, 2020

Coverage Status

Coverage decreased (-3.0e-05%) to 84.891% when pulling 18b8548 on ChrisJefferson:quit_gap into 8a0a129 on gap-system:master.

src/gap.c Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
else
QUIT_GAP(1);
QuitGap(1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Independent of this PR: looking at this PR, I discovered SetExitValue and learned that one could rewrite the above code as QuitGap(testTotalFailures = 0);. But I am not aware of any code using that. So, is it worth keeping this complication? If so, shouldn't we then actually use it here and elsewhere (perhaps not as part of this PR)?
On the other hand, it seems to me that code like QuitGap(testTotalFailures = 0);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I have used SetExitValue(1), so if GAP exits in the middle of my program (say because of an error), the exit value ends up set to a non-zero value.

Using QUIT_GAP(boolean), I don't remember ever seeing. We could probably remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at packages, there are a couple of QUIT_GAP(), but no passing in of booleans I can see.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that SetExitValue is useful to have, yes.

{
if ( LEN_LIST(args) == 0 ) {
SystemErrorCode = 0;
}
else if ( LEN_LIST(args) != 1
|| !SetExitValue(ELM_PLIST(args, 1) ) ) {
ErrorQuit( "usage: QUIT_GAP( [ <return value> ] )", 0, 0);
ErrorQuit( "usage: QuitGap( [ <return value> ] )", 0, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I am not aware of any code calling QuitGap or ForceQuitGap without an exit code. Are you? What would be a use case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I've done it myself. I suppose someone might want to just quit gap, but asking for a return value doesn't feel unreasonable.

Copy link
Contributor

@hulpke hulpke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems all harmless to me (and useful)

lib/obsolete.gd Show resolved Hide resolved
src/gap.c Outdated
**
*/

static Obj FuncGAP_EXIT_CODE(Obj self, Obj code)
static Obj FuncGapExitCode(Obj self, Obj code)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So tangentially related to this PR (which BTW needs to be rebased, then it could be merged): I just had need to query the exit code, and there simply is no way to do this. However, the natural name for a function to do this is taken... Can we either rename this to SetGapExitCode (and then later we can can add GapExitCode or GetGapExitCode to query it); or else change this function to return the exit code, and then also to allow calling it with 0 args, to just get the exit code w/o changing it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or how about SetExitCode -- or for that matter, SetExitValue which would match the kernel function (or conversely: rename the kernel function to match the function here...)

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good but needs to be rebased.

@fingolfin
Copy link
Member

I took the liberty of rebasing this PR.

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more tweaks for the documentations

doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
src/gap.c Outdated
**
*/

static Obj FuncGAP_EXIT_CODE(Obj self, Obj code)
static Obj FuncGapExitCode(Obj self, Obj code)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or how about SetExitCode -- or for that matter, SetExitValue which would match the kernel function (or conversely: rename the kernel function to match the function here...)

doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
doc/ref/mloop.xml Outdated Show resolved Hide resolved
@fingolfin fingolfin changed the title Switch QuitGap and ForceQuitGap to camel case Rename QUIT_GAP, FORCE_QUIT_GAP and GAP_EXIT_CODE to QuitGap, ForceQuitGap and GapExitCode (the old names remain available as synonyms) May 28, 2020
@fingolfin fingolfin merged commit 68b9452 into gap-system:master May 28, 2020
@ThomasBreuer ThomasBreuer self-assigned this Feb 17, 2021
@ThomasBreuer ThomasBreuer added release notes: added PRs introducing changes that have since been mentioned in the release notes and removed release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Feb 17, 2021
@ThomasBreuer ThomasBreuer removed their assignment Feb 17, 2021
@ChrisJefferson ChrisJefferson deleted the quit_gap branch April 1, 2022 08:17
@fingolfin fingolfin changed the title Rename QUIT_GAP, FORCE_QUIT_GAP and GAP_EXIT_CODE to QuitGap, ForceQuitGap and GapExitCode (the old names remain available as synonyms) Rename QUIT_GAP, FORCE_QUIT_GAP and GAP_EXIT_CODE to QuitGap, ForceQuitGap and GapExitCode (the old names remain available as synonyms) Aug 17, 2022
@fingolfin fingolfin added kind: removal or deprecation A feature was removed or deprecated / made obsolete and removed kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements labels Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: removal or deprecation A feature was removed or deprecated / made obsolete release notes: added PRs introducing changes that have since been mentioned in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants